The present invention relates to systems management, and specifically to an apparatus and method for automatic conversion of existing systems management software applications to run in multiple middleware runtime frameworks, such that multiple middleware runtime frameworks may be run without a full rewrite of their application source code.
A formidable problem an Automatic Test System (ATS) maintainer faces in the management of the system throughout its life cycle is when the computer system that runs the ATS station becomes obsolete. Even if the rest of the station is usable, the test program set (TPS) cannot be executed and the station cannot be controlled. Therefore, the entire ATS becomes unusable. This ultimately reaches a decision point on whether to support on-going activities; solutions that can prove costly and time consuming.
Systems management is a highly diversified area. There are numerous vendors of hardware components and many vendors of systems management software components. Lately, systems management software has seen high commoditization and movement towards middleware runtime frameworks, such as those based on IBM's WebSphere Application Server, Apache Tomcat, OSGi, Project Zero, and the Spring Framework, among others. Middleware is a computer software program that provides services to software applications beyond those available from the operating system. Generally described, it is the software layer that lies between the operating system and applications on each side of a distributed computing system in a network. Services that can be regarded as middleware include enterprise application integration, data integration, message oriented middleware (MOM), object request brokers (ORBs), and the enterprise service bus (ESB), to name a few.
With this shift to middleware runtime frameworks, it becomes more and more difficult for vendors of systems management software to support the multiple middleware runtime frameworks required by their customers. The situation aggravates exponentially when customers buy hardware parts from different vendors that require different system management components to be managed, and these components are based on (and only available on) different middleware runtime frameworks. Normally a big part of each system's management application would have to be rewritten to support multiple middleware runtime frameworks, which translates to high costs of development and maintenance.
As an example, management of a computer update must include consideration of the multitude of issues relating to the legacy software for an automatic test system (ATS). There remain several issues with regard to protecting the legacy data embedded within an individual Unit Under Test (UUT).
In many cases the source data for the various UUTs is not available to re-develop a test program set (TPS), either because the data was not purchased, or the UUT was so old that the data was no longer available.
Because of the radical difference in basic development concepts, an extensive re-development effort for the existing test program sets would necessarily be required, which is a timely and burdensome approach. Furthermore, it is not uncommon for many of the TPSs written for the existing UUTs that operate on automatic test system stations to have been through an extensive Independent Validation & Verification process. If a major redevelopment of the TPS were to occur, then this process would also have to be considered again as well which would be expensive and time consuming.
Considering these factors, the re-host and update of existing automatic test system stations is best served by a solution that will impact the existing legacy data (embedded in the individual UUT TPS) as little as possible.
One solution to this problem is to develop middleware that accomplishes this feat without impacting the legacy, underlying software programs. For example, U.S. Patent Publication No. 2013/0145348, titled “UNIVERSAL AND ADAPTIVE SOFTWARE DEVELOPMENT PLATFORM FOR DATA-DRIVEN APPLICATIONS,” discloses a platform-independent application programming interface and a software application that is independent of the rendering medium. Thus, the prior art recognizes the possibility to develop applications that can run across operating system platforms; however, applications that are capable of abstracting different presentation media are rare if not nonexistent.
Independence from the runtime platform is achieved by two means. First, the application platform represents a concise architecture with a corresponding application programming interface (API). The adherence to the API contract guarantees compatibility with the framework and desired results from the underlying platform. Secondly, the default implementation of the API is written in a language supported in multiple platforms, such as Java; however, implementations in other platform-independent languages such as C# and C++ can also be constructed.
Using a persistence layer in the application configured to abstract access to a database residing on a physical storage medium, the persistence layer is capable of abstracting access to data records adaptively at runtime without hard-coding specific information about each record type.
It is noted that the '348 Publication does not teach a collection of ontologies associated with target runtime framework, or an algorithm that identifies runtime functions.
In U.S. Patent Publication No. 2008/0216050, titled “METHOD AND SYSTEM FOR ACCESSING A RESOURCE IMPLEMENTED IN A COMPUTER NETWORK,” A method and system for accessing a resource transparently from a client perspective is taught, which makes the access method independent of the underlying runtime environment.
The '050 Publication implements runtime and platform independent steps which can be advantageously supported by specific tooling in one of the prior art development environments. By means of this approach, a developer is allowed to remain in the platform and runtime independent “arena” as generalized or generically available interfaces are used to do the implementation of the web service itself.
The prior art, however, is silent with respect to providing a method for automatic conversion of existing systems management software applications to run in multiple middleware runtime frameworks without a full rewrite of their application source code. It is also does not teach or suggest collecting ontologies (metadata that describes the elements and behavior of a model) associated with each supported target runtime framework; nor an algorithm for identifying runtime-dependent functions/methods/arguments in these components.